This section is intended to introduce the reader to various aspects of art, which may be related to various aspects of the present invention that are described and/or claimed below. This discussion is believed to be helpful in providing the reader with background information to facilitate a better understanding of the various aspects of the present invention. Accordingly, it should be understood that these statements are to be read in this light, and not as admissions of prior art.
Media delivery streaming solutions are mainly based on protocols such as Real time streaming Protocol (RTSP) as defined in the IETF RFC 2326, Microsoft Media Server (MMS) proprietary protocol from Microsoft or Real Time Messaging Protocol (RTMP) proprietary protocol from Adobe Systems. More recently new streaming techniques based on HTTP protocol have emerged. Adaptive streaming technology provides a way to compensate erratic network behavior regarding available bandwidth by continuously and gracefully upgrading or downgrading the video quality in order to fit with the bandwidth constraint. More precisely, a video stream is encoded into several encoded bit streams, each corresponding to a bit rate constraint, such as for example 300 kbps, 600 kbps, 1200 kbps 2000 kbps or 3000 kbps. Each of these streams is then split into chunks, representing for example two seconds duration, all well aligned in a way that each chunk starts with a reference frame; no frame of any given chunk references a frame in another chunk. In other words, the video stream is cut into short segments called chunks and encoded to the desired delivery format. Chunks are typically 2-to-4-seconds long. At the video codec level, this typically means that each chunk is cut along video Group of Pictures (GOP) boundaries and has no dependencies on past or future chunks and GOPs. This allows each chunk to later be decoded independently of other chunks.
A client device requests a HTTP server, to send a chunk attached to a particular bit rate regarding the estimated bandwidth, where the available bandwidth can be measured e.g. by measuring the round trip time used by of an HTTP request/response. The video stream is then delivered, chunk after chunk based on client requests. This is illustrated in FIG. 1, which shows four levels of chunk bit rates, from the lower to the upper bit rate. Video chunks, all corresponding to a fixed duration, are more or less large. A large chunk requires higher bandwidth and provides better video quality. The chunk selection depends on the estimated available bandwidth that corresponds to the curve. Of course, depending on the implementation, the environment, the network technology and the client application, the strategy may be more or less conservative. When conservative, the client requests higher bit rate chunk only after a certain time, ensuring smooth upgrade transition. A less conservative strategy would be to request higher bit rate chunk as soon as the client detects that more bandwidth is available. And in general, the client requests lower bit rate chunk as soon as it detects a bandwidth decrease implying rapid downgrade transition.
Examples of such streaming techniques are the “Move Adaptive Stream” from Move Networks, the “HTTP Live Streaming” from Apple Inc. and the “IIS (Internet Information Services) Smooth Streaming” from Microsoft. The benefit of using the HTTP protocol in these streaming solutions is its capability to cross over NAT and firewall seamlessly. These HTTP streaming technologies provide a way to compensate erratic network behavior regarding available bandwidth by continuously and gracefully upgrading or downgrading the video quality in order to fit with the bandwidth constraint.
In more details, WO 2005/109224 A2 from Move Networks describes a mechanism in an Agent Controller Module hosted in the client side and able to adapt to the fluctuant network bandwidth thanks to the fact that the media to stream is previously organized in a plurality of streamlets, also called chunks, each of them being encoded from low to high bit rates. According to the available network bandwidth and some other additional information a monitoring tool incorporated in the Agent Controller Module uses the HTTP protocol to request the server to send the best suited chunk to be streamed over a TCP/IP connection. On an elementary chunk basis the quality is up-shifted or down-shifted according to the Agent Controller Module.
The IIS Smooth Streaming Technical Overview, from Alex Zambelli, Microsoft Corporation, March 2009, describes the IIS Smooth Streaming Technique based on HTTP protocol over TCP/IP connection. The media to be streamed by the Server is previously chopped into chunks representing for example one to ten seconds duration. Then these chunks are encoded according to the H.264/MPEG-4 AVC standard at different bit rates and stored within a MP4 file format container. The mechanism selecting the bit rate according to the network bandwidth fluctuation and requesting seamlessly the corresponding chunks to the server is entirely implemented in the client side through an application code, the Silverlight application. The HTTP Live Streaming supports dynamic switching between streams of different data rates in response to changing connection speeds.
Apple Inc. submitted an Internet Draft to IETF in October 2009 on an HTTP streaming method specification entitled “HTTP Live Streaming draft-pantos-http-live-streaming-02”. The HTTP streaming architecture is based on 3 pillars: a Server, a Distribution, through a Web server or a Web caching system, and a Client. The media to be streamed is a video encoded in H.264 and an audio encoded in AAC. At a server, it is encapsulated in MPEG-TS containers and fragmented into chunks of equal duration with a specific tool named Apple stream segmenter. This tool generates the chunks that are saved into *.ts files and an index file *;m3u8 constituting the chunks playlist. Then a client fetches the index file first thanks to an URL pointer. The index file in turn specifies the location of the available media files, decryption keys, and any alternate streams available. For the selected stream, the client downloads each available media file in sequence.
With such adaptive streaming techniques, the video quality is irregular. A stream acquired by a client chunk after chunk does not have a consistent quality as it is a mix of different bit rate chunks. That video may be stored at the receiver to be replayed later on. Usually with such streaming applications, there is no need to resend the stream over the network as the chunks could have been recorded in a local storage facility. However the series of recorded chunks correspond to the network conditions that were experienced during the streaming session resulting in the non consistent quality of the video.
A solution to this problem would be to reacquire from the server the chunks corresponding to the low quality chunks. This can be done as a grouped download before the recorded stream is replayed. However this may be time consuming. Another solution is to replace the low quality chunks on-the-fly during the recorded stream playback. There is no guaranty however that the client would get better quality chunks at the time they are needed either. And, both solutions oblige the client to be connected to the server.